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THE FOUR FORMS OF Q 

Alternate Syntactic Forms for an Object-Oriented Language 



Bruce J. MacLennan 
Computer Science Department 
Naval Postgraduate School 
Monterey, CA 93943 



1. Introduction 

In this report 1 we describe four alternative syntactic forms for the object-oriented language H, described in 
our View of Object-Oriented Programming (Naval Postgraduate School Computer Science Dept. Tech. 
Rept. NPS52-83-00I, Feb. 1983). Additional information on a prototype implementation of Q can be 
found in Heinz M. McArthur’s Design and Implementation of an Object-Oriented , Production- Rule Inter- 
preter (Naval Postgraduate School Master’s Thesis, Dec. 1984). 

It must be emphasized that these notations are all different concrete representations for the same 
abstract language. Thus, for example, rules could be entered in one form and displayed in another. This 
permits different U3ers (or the same user at different points in time) to look at a program in different 
ways. 

The first syntactic form, fij, uses a predicate logic style. It is also the simplest to parse. The second 
and third styles (0 2 and 0$) have a stylized natural language format. As a result they are less compact, 
but more readable to computer-naive users. The fourth form, H 4 , drops the linear syntax of the other 
three, and adopts a two-dimensional format based on the idea of a form. It is the least compact, but most 
amenable to use by computer-naive users. 

We describe each of these forms in the body of this report, and illustrate the forms with a simple 
example. A formal grammar for each format appears in the Appendices. 



1. Work reported herein was supported in part by the Office of Naval Research under contract number N0001 4-85-24057. 
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2. First Form 



The first form, Qj is based on a predicate-logic style notation. It will look familiar to readers acquainted 
with logic programming languages and production rule systems. The basic construct is the rule , which 
has the form 

cause => effect 

The cause describes a possible situation in a space of objects connected by relations. If that situation 
holds, then the rule may be applied, which means that the actions described by its effect part will be per- 
formed. Rules are executed indivisibly, which means that it is guaranteed that the situation still holds 
when the actions are performed. 

There is normally no order implied between rules; they can be tested in any order. However, rules can 
be connected by the word else when a particular order must be imposed: 

cause j => effect j 
else cause 7 => effect 7 

else cause n => e//ec< n 

In this case, the second and succeeding rules are tried only when the preceding rules have failed. 

The cause part of a rule describes a situation in terms of one or more conditions, which represent the 
presence or absence of relationships between objects: 

conditionj, condition 7 , . . . , condition n 

All of these conditions must be satisfied before a rule can be applied. 

A condition for testing for the presence of a tuple in a relationship has the form: 

primary ( pattern j, pattern 7 , . . . , pattem n ) 

The primary is an expression (usually just an identifier) that evaluates to a relation. The following list of 
patterns defines a tuple pattern . Each pattern in the list can be either an free (i.e., undefined) variable, or 
an expression containing no free (i.e., only bound) variables. An expression is evaluated during the 
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matching process, and matches a value equal to the result of its evaluation. A free variable will match 
any value, but becomes bound to that value during the matching process. The special free variable 1 
can be used to match anything without binding a variable name. 

A condition for testing for the absence of a tuple from a relationship has the form: 

primary ( pattern j, pattern 2 , . . . , pattem n ) 

This condition succeeds only if there is not a tuple of the specified form in the relation that is the value of 
the primary. 

Finally, as a convenience we permit cancel conditions: 

*primary ( pattern lf pattern 2 , . . . , pattem n ) 

This tests for the presence of a tuple of the specified form, just as the first kind of condition, but it has a 
side effect of deleting that tuple if the rule is applied. Although, this could be programmed explicitly, the 
situation is common enough that it is important to reflect it in the notation. 

The effect part of a rule is composed of a sequence of transactions: 

transaction j, transaction 2f . . . , transaction n 

These transactions can be performed in any order or in parallel. The transactions are of four kinds: asser- 
tions, denials, calls and sequential blocks. 

An assertion is a transaction of the form: 

primary ( expression expression 2 , • • • , expression n ) 

Its effect is to add to the relation that is the value of the primary the tuple < V u V 2f . . . , V n >, where 
each K, is the value of expression . Typically these expressions contain variables that were bound in the 
cause part of the rule. 

A denial has the form of an assertion preceded by a negation sign: 

-» primary ( expression Xy expression 2 , . . . ; expression n ) 

Its effect is to delete the specified tuple from the specified relation. If this relation does not contain this 
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tuple, then an error condition holds. 



A call is a transaction of the form: 



primary { expression ly expression 2 , . . • , expression n } 

Its purpose is a form of synchronous communication performed by sending a message through one relation, 
and waiting for a reply to be returned through another relation. For example, the call 

P{E,F } 



has the effect of performing the assertion 

P(a,E,F) 

Here a is a newly generated relation that will be used for receiving the reply. This assertion presumably 
requests some actions to be performed by other rules (which are watching P). When the actions are com- 
pleted, an acknowledgment or reply will be placed in the a relation, which permits the calling rule to 
complete. Note that rules containing calls in their effect parts are not considered indivisible. 



The last kind of transaction is a sequential block, which has the form: 

{ statement |j statement 2 ; * * * ; statement n } 



The effect of this construct is to execute the component statements in order. A statement is simply a 
rule, simple or compound, with the additional characteristic that its cause part (and the =>) can be omit- 
ted. This reflects the fact that in a sequential block the performance of actions may be conditioned solely 
on the performance of the preceding statements. 



A user normally interacts with an 0 system by typing statements, 
session is: 



Thus the form of an H terminal 



statement f, 
statement 2 \ 



statement n ; 

Many of the statements typed interactively are isolated effects containing a single call. For example, to 
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define ‘Contents’ to be a new private relation, a user would enter: 

Define{ Private, ‘^Contents”, NewRel{) }; 

Finally, we need a means for manipulating groups of rules as a unit; this is the rule denotation and has the 
form: 

« compound — rule j. compound — rule 2 . 

Notice that each compound rule is terminated by a period, 
contain elses.) 

There follows an Qj session to declare an abstract type 
mands defines the relations that characterize stacks. Next 
for managing stacks. Finally, a group of definitions make 
tricted capabilities. 



* • * compound —rule n . » 

(A compound rule is simply a rule that may 

manager for stacks. The first group of com- 
comes a rule denotation containing the rules 
certain of the relations public, but with res- 
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STACKS IN Hj 



Define {Private, “Contents”, NewRel{}}; 

Define {Private, “Push”, NewRel{}}; 

Define {Private, “Pop”, NewRel{}}; 

Define {Private, “Destroy”, NewRel{}}; 

Define {Private, “NewStack”, NewRel{}}; 

Define {Private, “Rules”, 

«*Push(A , X ,5 ), *Contents( Y ,S ) => Receives(A ,5 ), Contents(cons[ X , Y ], S ). 

*Pop(A ,5), *Contents(A r ,5 ) => Receives(A ,first [ ] ) , Contents(rest[ X ],5 ). 

*NewStack(A ), *Avail(5 ) => Receives(A ,5), Contents(nil,5 ). 

*Destroy(A ,5 ), *Contents( X ,5 ) => Receives(A ,X). » }; 

Activate {Rules}; 

Define {Public, “Push”, AddOnly{Push}}; 

Define {Public, “Pop”, AddOnly{Pop}}; 

Define {Public, “Destroy”, AddOnly{Destroy}}; 

Define {Public, “NewStack”, AddOnly{NewStack}}. 

5. Second Form 

The second form of 17 attempts to achieve a more natural notation by permitting relations to be named 
by templates. For example, we can denote the Contents relation by the template: 

— is contents of — 

Then, instead of using the notation ‘Contents ( X ,5 )’, we can write *X is contents of 5 \ Using the more 
mnemonic Mist’ and ‘stack’ in place of ‘A’’ and ‘5’ yields ‘list is contents of stack’. Finally, 17 2 promotes 
readability by allowing the use of “noise words”: 

a list is the contents of the stack 

Here, ‘a’ and ‘the’ are noise words inserted to improve the continuity of the clause. 
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Relations that are intended to be called as procedures should have ‘does’ as the first word in their tem- 
plate. For example, the template for the Push relation is: 

— does push — on — 

Inquiries and assertions to this relation are made in the usual way, by filling in the blanks: 

the agent does push the thing on the stack 



However, the relation can be called synchronously by omitting the first argument and the word ‘does’ 
(thus converting the declarative into an imperative): 



push the thing on the stack 



This is analogous to the Hj notation 



which is equivalent to 



Push {thing, stack} 



Push (agent, thing, stack) 



Templates that do not begin with ‘does’ cannot be called as procedures. 

An inquiry or assertion is negated by placing the word ‘not’ after the first word in the template, for 
example, 



the list is not the contents of the stack 



The same rule applies to ‘does’ templates: 

the agent does not push the thing on the stack 



The structure of rules in H 2 is the same as in (i u except that all rules are preceded by ‘When’ and the 
word ‘then’ replaces the arrow ‘=$>’. The Qj cancellation symbol, is replaced by the word ‘given’ in 
n 2 . In other respects the syntax of H 2 closely follows that of flj. 
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STACKS IN n 2 

Define private name is contents of — ” to be make new relation; 

Define private name does push — on — ” to be make new relation; 

Define private name does pop — ” to be make new relation; 

Define private name does request a new stack” to be make new relation; 

Define private name does destroy — ” to be make new relation; 

Define private name “Stack Rules” to be 
the rules 

When given an agent does push a thing on a stack 
and given a list is the contents of the stack 
then the agent does receive the stack 
and the appending of the thing and the list 
is the contents of the stack. 

When given an agent does pop a stack 
and given a list is the contents of the stack 
then the agent does receive the first element of the list 
and the rest of the list is the contents of the stack. 

When given an agent does request a new stack 
and given a thing is available 
then the agent does receive the thing 
and nil is the contents of the thing. 

When given an agent does destroy a stack 
and a list is the contents of the stack 
then the agent does receive the list. 

end rules; 
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Activate the Stack Rules; 

Define public name does push — on — ” 
to be an add only version of does push — on — 

Define public name does pop 
to be an add only version of does pop 
Define public name does request a new stack” 
to be an add only version of does request a new stack”; 

Define public name does destroy — ” 
to be an add only version of does destroy — 

4 . Third Form 

The syntax makes an additional step in the direction of a more natural notation: the provision of ana- 
phoric reference. To explain this we need some grammatical terminology. First, phrases which denote a 
value or object, such as 

a list 

a brother of Joe 
the owner of the file 
something which is moving 
that which receives the result 

are called noun phrases. Second, phrases that describe a state, condition or relation, and normally stand 
after a form of the verb to be, such as 

hot 

less than 100 
between 20 and 50 

are called adjective phrases. Finally, phrases that describe a state, condition, relation or action, and either 
do not contain a form of to be, such as 
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moves 



does pop the stack 

does not push the object on the stack 
connects the terminal to the processor 

or contain a form of to be followed by a noun or adjective phrase, such as 

is a list 

is less than 100 
is not the brother of Joe 
is something which is moving 

are called verb phrases. 

A few simple examples will illustrate the idea of anaphoric reference. Suppose that we have the fol- 
lowing inquiries in the cause part of a rule: 

T is a terminal and T is available 

Anaphoric reference permits this to be written 

a terminal is available 

The indefinite determiner ‘a’ before the noun ‘terminal’ implies an inquiry of the form ‘ T is a terminal’. 
Furthermore, the use of the phrase ‘a terminal’ in the clause ‘a terminal is available’ implies that it is the 
same terminal T that is available. In essence use of the phrase ‘a terminal’ implies the existence of an 
object or value X having the property ‘X is a terminal’. 

More specifically, the indefinite determiners ‘a’ and ‘an’ before a noun N are equivalent to X and 
generate an inquiry 

X is N 

Thus, the clause ‘an N VP’, where VP is a verb phrase, reduces to the two clauses l X is N and X VP’. 
The same rule applies even if the noun is followed by arguments. For example, the inquiries 

A' is a brother of John and X is moving 
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can be written 



a brother of John is moving 

Note that anaphoric reference requires to distinguish between nouns, adjectives and verbs. 

We turn to a more complicated example. Suppose we have the inquiries: 

T is a terminal and T is available and T is not broken 
Anaphoric reference permits this to be written: 

a terminal is available and the terminal is not broken 

The use of the definite determiner ‘the’ in the phrase ‘the terminal* guarantees that the terminal in ques- 
tion is the same one referred to earlier in the rule. 

Definite determiners are also permitted in the effect parts of rules. For example, the rule 

When T is a terminal and given T is available then T is allocated. 

can be written 

When given a terminal is available then the terminal is allocated 
The phrase ‘the terminal* in the effect part refers to the same terminal mentioned in the cause part. 
Finally, fi s provides a limited ability for subordination. For example, the inquiries 
X connects the terminal to the processor and X is not busy 

can be written 

something which connects the terminal to the processor is not busy 

In general, if VP is a verb phrase, then the clause ‘something which VP* is equivalent to X and generates 
an inquiry of the form ‘ X VP*. In other words, the clause 

something which VP VP' 

reduces to the two clauses 

X VP and X VP' 
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Similarly, the phrase ‘that which VP’ refers back to something X in a previous inquiry of the form l X 
VP\ Indeed, the phrase ‘a/an NP’ can be considered an abbreviated form of ‘something which is NP’, 
and ‘the NP’ can be considered an abbreviated form of ‘that which is NP’. 

Another permitted form of subordination is illustrated by the following example. The inquiries 

a channel is connected to a device and the device is not busy 

can be written 

a channel is connected to a device which is not busy 

In general the phrase ‘NP which VP’ is equivalent to NP, but generates the additional inquiry ‘NP VP’. 
The use of anaphoric reference and subordination eliminates almost entirely the need for variable names in 
rules. 

The stack example is almost identical in f) 2 and 0$: 

STACKS IN 

Define private noun “contents of—” to be make new relation; 

Define private verb “does push — on — ” to be make new relation; 

Define private verb “does pop — ” to be make new relation; 

Define private verb “does request new stack” to be make new relation; 

Define private verb “does destroy — ” to be make new relation; 

... remainder as in H 2 ... 

5. Fourth Form 

The two-dimensional H syntax, fl 4 , is based on the idea of forms. These can be thought of, and are 
displayed like, paper forms with fields that can be filled in with values. In particular, a relation is con- 
sidered to be a blank form (i.e., a template), and each tuple in a relation is considered to be a filled out 
instance of that form. 

Users can explicitly create or delete form instances, that is, add or delete tuples to or from relations, 
by selecting a form name (relation name) from a menu and filling in the fields of the form. This is a very 
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natural mode of operation for offices and similar environments. To demonstrate this, we use a form- 



oriented terminology to describe the syntax of 0 4 . 

A rule is represented by a rule window labeled with the rule’s name: 

rule name 



If the rule is part of a compound rule, then the right half of the rule’s title chains to the alternative rule: 



rule name x 


else: rule name 2 






rule name 2 


else: rule name$ 







rule name s 



Each rule window is divided into two frames , an upper situation frame (the cause) and a lower action 
frame (the effect): 

name 

situation 



action 

The situation frame is occupied by zero or more condition pan es, which represent the presence or absence 
of form instances (tuples in relations). A condition pane has tl le format: 
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relation name 



field— name x : field— pattern x 
field— name 2 : field— pattern 2 



field— name n : field— pattern n 
This kind of condition pane tests for the presence of the specified form instance (tuple). 

The field- patterns can be either constants or variables. If they are constants then the pane will only 
match a form instance in which that field is filled in with that value. If the field-pattern is a variable, 
then the variable can be either unbound or bound. If it is unbound, then it will match any field-value, 
and will become bound to that field-value. If it is bound, then it matches only the value to which it is 
bound. Field-patterns can be left blank, which has the effect of filling them in with new, unique, unbound 
variables. Thus, blank field-patterns are considered “don’t cares” since they match anything. 

The absence of a form instance is indicated by appending the modifier ‘(absent)’ to the form (rela- 
tion) name: 



relation name (absent) 


field - name x : 


field- pattern x 


field— name 2 : 


field— pattern ^ 


field— name n 


: field— patter n n 



Similarly, to test for the presence of a form instance, and delete the form instance when found, we append 
the modifier ‘(delete)’: 
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relation name (delete) 


field— name x : 


field — pattern j 


field— name j: 


field— pattern 2 


field- name n 


: field— patter n n 



Finally, there is a special condition pane, called a constraint pane , which can appear in the situation 
frame; 

Constraint 
Boolean expression 

There can be any number of constraint pane in the situation frame; they must all evaluate to true for the 
rule to apply. 

The action frame is filled with a number of transaction panes. A transaction pane can have four for- 
mats: creation, deletion, procedure, or sequential process. A creation pane has the form: 



relation name 


field— name f. 


field— value j 


field— name 2 : 


field— value 2 


field— name n : 


field— value n 



This calls for the creation of the specified form instance. The field- values are expressions used to compute 
the values for the fields. 



- 15 - 



Ur 



A deletion pane calls for the deletion of the specified form instance: 



relation name (delete) 

field — name j: field— value j 
field— name 2 : field- value 2 

field— name n : field— value n 



The third kind of action pane is a procedure or call pane: 



relation name (procedure) 

field— name j: field— value x 
field— name 2 : field— value 2 

field— name n : field— value n 

This calls for a synchronous call of the specified relation. That is, the form instance is created, which 
requests some action to be performed. The rules containing the procedure call is not considered complete 
until the completion of the requested action is acknowledged via an ‘Acknowledgement’ form. 

The last kind of transaction pane is a sequential process pane: 



Sequence 


1: 


statement j 


2: 


statement 2 


n 


statement n 



The statements are executed in the order listed. They may be either the names of rule windows, or 0 
rules in one of the linear forms (Qj, Q 2 , or fi 5 ). 



Finally, we need a means for manipulating groups of rules as a unit; this is the rule-group window: 
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Rules: group name 

rule — name j 
rule — name 2 

rule — name n 

For example, a request to activate a rule group will activate all the rules named in that group. 
A specification of the stack example in f l 4 follows. 
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STACKS IN n 4 

Rules: Stack Rules 

Push Rule 
Pop Rule 
New Stack Rule 
Destroy Stack Rule 



Push Rule 


Push Request (delete) 


Stack Contents (delete) 


From: A 


Stack: S 


Item: X 


List: Y 


Stack: S 




Acknowledgement 


Stack Contents 


To: A 


Stack: S 


Concerning: S 


List: appending of X and Y 



Pop Rule 


Pop Request (delete) 


Stack Contents (delete) 


From: A 


Stack: S 


Stack: S 


List: X 


Acknowledgement 


Stack Contents 


To: A 


Stack: S 


Concerning: first of X 


List: rest of X 
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New Stack Rule 


New Stack Request (delete) 


Available Object (delete) 


From: A 


ID: S 


Acknowledgement 


Stack Contents 


To: A 


Stack: S 


Concerning: S 


List: nil 



Destroy Stack Rule 


Destroy Stack Request (delete) 


Stack Contents (delete) 


From: A 


Stack: S 


Stack: S 


List: X 


Acknowledgement 




To: A 




Concerning: X 





Dialog 

27: Activate Stack Rules; 

28: Define public Push Request to be create-only Push Request; 

29: Define public Pop Request to be create-only Pop Request; 

SO: Define public Destroy Stack Request to be create-only Destroy Stack Request; 
31: Define public New Stack Request to be create-only New Stack Request; 

32: 
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APPENDIX A: ABSTRACT SYNTAX OF 0 



Session = statement —list 

statement — list = <statement— list; statement ; statement —list? > 



(nil \ 

statement -l, st f = ^ <fatcmcnt _ litt j 

{ <else; rule ; statement >\ 
<rule; cause ? ; effect ? > J 

compound — rule = <cpd; rule ; statement? > 

(nil \ 

statement = \ . . .( 

I statenentj 

rule = <rule; cause ; effect? > 
cause = <cause; condition ; cause? > 
nil \ 



cause? — 



cause 

/ 

condition = < 



■ 



<present; inquiry > 
< absent; inquiry > 
ccancel; inquiry > 



inquiry — <inquiry; primary ; tupl —pattern > 

( <tupl; pattern ; tupl —pattern? >\ 
<arbtupl; pattern ; pattern > J 



nil 



tupl -pattern? = 1 tup , _ patter J 



pattern — 



j free-variable\ 



\ 



expression 



i 



free- variable = 



/nil 1 

1 <var; string > J 



effect? = 



effect) 



effect — <effect; transaction ; effect? > 

\ 

<assert; predication > 
<deny; predication > 
call 

seq — block 



transaction = 



predication = <predication; primary ; arguments f > 



( nil 

arguments f = 1 . 

y \ arguments 



arguments = <arguments; expression ; arguments? > 
call = <call; primary ; arguments f > 



seq — block = <seq-block; statement — list > 



expression 



<binop ; expression ; expression > 
* <unop ; expression > 
primary 



binop 



/ \ 

or 

and 
eq 
ne 
It 
gt 
41 le 
ge 
sum 
dif 
prd 
quo 
mod 

V / 



unop 




primary 



list = 



listing 



f <con ; value > ^ 

<selfref; var > 

<var; string > 

<apply; var ; arguments > 
<eval; expression ; expression > 
list 
call 

^<rule-den; statement - list > , 



( listing 

<cons; expression ; expression 



ion 



t 



nil I 

<\ist\expression ; listing >) 
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APPENDIX B: SYNTAX OF Hj 



Session = statement — list 
statement — list = statement ; 



statement = 



rule else statement^ 
(cause =>] effect J 



compound — rule = rule [ else statement 
rule — cause => effect 
cause = [if] condition , 



condition = 



inquiry 



inquiry = primary ( tupl — pattern 
pattern , * * • 



tupl — pattern = 



pattern : pattern) 



( free- variable] 
f 

expression J 



free- variable = ) . u 

l variable) 

effect = [ transaction , * 

/ \ 

assertion 

denial 

call 

seq — block 



transaction = 



V 



assertion = predication 

denial = -> predication 

predication = primary ( arguments ) 

call = primary { arguments } 

arguments = [expression , * * * ] 

seq -block = { statement — list } 

expression = [expression V ] con/uncfion 

conjunction = [ conjunction A ] I -1 ] relation 
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relation = [simplex relator ] simplex 
relator = {=|^|<|>|^|^} 

simplex = [simplex {+ | — }] term 
term = [term {* | / | %)\ factor 



factor 




primary 



primary = primitive [: primary ] 



primitive = 



/ \ 

constant 

(@ ) variable 
primitive [ arguments ] 

( expression ) 

/ expression , * * * 
expression : expression j 

call 

rule — denotation 



■i: 



conaJan* = 



dipt* + 



{ c/iaM 



nil 



rule — denotation = « { compound —rule ■ > » 
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APPENDIX C: SYNTAX OF 0 2 



Session = statement — list . 
statement —list = statement ; * * * 
rule else statement] 



/ « 

statement = then] e//ecf J 

compound — rule = rule \ else statement ] 
rule = cause then effect 
cause = When condition and * * * 
condition = [given] inquiry 

{ word [not] \ t 

does [not] word J wor< * \ tu pl ~ patter 

( free- variable] 
primary j 

( anything^ 
variable j 

( pattern {word* pattern) ^ 
arbitrary pattern j 

( variable ^ 

I 

expression] 

noise — word = { a | an | the } 

effect = [ transaction and * ] 

/ \ 

predication 

call 



transaction = < 



seq — block 



( word [not] \ 
does [not] word) WOr ^ [arguments ] 

call = [noise — word ] word + [arguments] 
arguments = expression {word + expression) 
seq —block = begin statement — list end 
expression = [expression or] conjunction 
conjunction = [conjunction & ] [not] relation 
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relation = [ simplex relator ] simplex 

relator = {=|^|<|>|^|^} 



simplex = [simplex {+ | — }] term 
term = [term {* | / | %}\ factor 

+ 



factor = 



primary 



primary = primitive [: primary ] 

/ \ 

constant 

[own] variable 

word* of arguments 

primitive = ( expression ) 

{ expression , * • • 

expression append expression j I 
call 

rule — denotation 



iion| 



constant = 



digit + 

,,f char \ " 



V"7 



nil 



rule — denotation = rules { compound — rule . } end rules 
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APPENDIX D: SYNTAX OF 



Session — statement —list . 

statement — list = statement ; • • * 

{ rule else statement ^ 

[ cause then] effect J 

compound — rule = rule [ else statement 

rule - cause then effect 

cause = When condition and * 

condition = [given] inquiry 

inquiry = noun — phrase verb — phrase 



/ # \ 
determ noun arguments which verb — phrase 



noun phrase = i 



( that ^ 

\ something/ which verb ~P hrase 



expression 



verb —phrase — 



verb [not] arguments 
does [not] verb arguments 

( noun — p/ira«e^ 
adj — phrase ) 



adj — phrase = adjective arguments 

{ prep — phrase \ 

• LI I 

arbitrary variable) 

prep — phrase = [ preposition ] noun —phrase 

effect = [transaction and * * * ] 



/ 



transaction = < 



declaration 

call 

seq — block 



declaration — noun — phrase verb —phrase 
call = verb arguments 
seq— block = begin statement —list end 
expression = [ expression or] conjunction 
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conjunction = [ conjunction &] (not] relation 

relation = [simplex relator ] simplex 
relator = {=|^|<|>|$|^} 

simplex - [simplex {+ | — }] term 
term = [term {* | / | %}] factor 



factor 



+ 



primary 



primary 



primitive 



constant 



primitive [.primary] 



/ 

constant 
(own] variable 
primitive [arguments ] 

( expression ) 

{ expression , * ■ * 

expression append expression, 

call 

rule — denotation 



\ 







rule — denotation = [the] rules { compound — rule 



determ = < 




noun = word + 



verb = word + 
adjective = word + 
preposition = word + 



} # end rules 
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APPENDIX E: SYNTAX OF H 4 



Session = 



statement — list — 



compound — rule — 



or 



Dialog 

statement — list 



1: statement ! 

2: — statement 2 

n : n 3 -*fatement n 



else: 



effect 



cause 



effect 



cause = condition + 
condition = 



name 


[ (modi/ ter ) ] 


name j: 


pattern j 


name n 


: pattern n 



(If the Field names are first and rest, then the pattern matches the First and rest of an arbitrary tuple.) 

{ delete ^ 
modifier = | ab8ent j 

( variable \ 

o I 

expression J 

effect = transaction 



transaction = 



( nonsequential \ 
sequential J 



nonsequential = 



kind 



( 



delete 

procedure 



name [ ( kind ) ] 
name j: n s - expression , 

name n : expression^ 
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sequential = 

Sequence 
statement — list 



rule — denotation = 

Rules: name 
name x 

name n 
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APPENDIX F: INCOMPATIBILITIES WITH MCARTHUR PROTOTYPE 



There axe a number of minor syntactic incompatibilities between the dialect of Qj implemented by the 



McArthur prototype and that described in this report. 

1. To simplify parsing, the keyword if is required on all rules with a nonnull cause. 

2. The lexical representation of is ‘->\ and strings are surrounded by the ASCII double quote sym- 
bol. 

3. Additional degenerate forms of rules, such as ‘if cause are permitted. 

4. A user can enter multiple sessions , each terminated by a period. The period calls for the execution of 
all statements in that session. The semicolon statement termination does not cause execution. 
Rather, the statements are saved until the next period. 

5. The McArthur prototype does not distinguish between statements and compound rules. The result is 
that it is possible to activate rules with an empty cause part. 

6. Arbitrary expressions are permitted as transactions. 

7. The object-oriented language Q is augmented with an applicative sublanguage. To support this, 




/ ormals 




and 



compound — expression = cond — expression else * 
cond — expression = [if expression =s>] expression 



8. Mutually recursive functions are declared by means of a “forward” declaration: 
function /[•*•]: nil; 



function / [ 
function g [ 
function / [ 



/ 




This ensures that / is bound before it’s used in g , and that g is bound before it’s used in / . 
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